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(57) Abstract: The invention relates to a user interface-equipped computing device comprising means for implementing a series of 
applications, said means including two execution spaces. According to the invention, the applications of the second execution space 
(100, PI, 200, P2) have a level of security specifically higher than that of the applications of the first execution space (100, PI, 200, 
P2), said two execution spaces being hosted by a physical processing means which is designed such that it cannot be separated into 
two parts without destroying the physical processing means. 
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(57) Abrege : L'invention conceme un dispositif informatique a interface utilisateur, comprenant des moyens de mise en oeuvre 

d'une serie d'applications, ces moyens incluant deux espaces d'execution, les applications du second espace d'execution (100, PI, 
200, P2) etant des applications a degre de securite specifiquement plus eleve que celui des applications du premier espace d'execution 
(100, PI, 200, P2), les deux espaces d'execution etant heberges par un moyen physique de traitement qui est agence pour etre non 
scindable en deux parties sans destruction de ce moyen physique de traitement- 
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1 

TERMINAL DE TELECOMMUNICATION A DEUX ESPACES D'EXECUTION 

L'invention concerne Texecution de programmes et applications, sur 
un dispositif Informatique a interface utilisateur (clavier, ecran, carte son, 
5 zone tactile, souris, etc...)i P^r exemple sur une passerelie domestique, 
une machine de vente (machine publique par exemple) ou encore sur un 
terminal de telecommunications (du PC - ordinateur personnel - au 

telephone mobile). 

On connaTt differentes approches pour {'implementation 
d'applications dans les terminaux de telecommunications. 

Ainsi, le profil MIDP 2.0. , sur machine vlrtuelle, met en oeuvre une 
police de securite basee sur des standards ouverts, simple a utiliser, qui ne 
demande rien a Tutilisateur, qui prend en compte les besoins de chaque 
intervenant, du developpement a Texecution (on separe les concepts 
d'utilisateur, d'operateur, d'OEM, de tierce partie de confiance). 

II permet de proteger I'integrite et verifier Torigine des applications 
pendant le teiechargement et I'execution de celles-ci, de controler Tacces 
aux ressources critiques suivant une politique de securite, d'avertir 
I'utilisateur de ce qui se passe, et peut meme lui demander son avis. 

La prise en compte de la politique de securite se fait assez 
simplement, au niveau d'une API a proteger, par un appel a la methode 
« check permission » de la classe « Midiet » (figure 2). 

Ceci demande que la fonction d'appel de^fichier MIDP ne soit pas 
accessible directement depuis les programmes MIDP (fonction protected). 

La politique de securite de MIDP 2.0 est tres adaptee aux besoins 
des divers intervenants. La possibilite de demander Tavis de I'utilisateur 
suivant un certain nombre de criteres (toujours, une fois, pour une session, 
jamais) est tres avantageuse. 

II n'en reste pas moins que son implementation pose deux types de 

problemes. 

Tout d'abord, Texecution de la procedure protegee se fait dans le 
meme espace d'execution que le programme appelant, ce qui facilite le 
risque de « fuites ». Imaginons ainsi un service de chiffrement appele par 
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deux midlets simultanement, rien ne garantit si on n'y fait guere attention 
qu'une midlet ne pourra recuperer le contenu de la cle privee utilisee par 
I'autre midlet. 

Le premier probleme est done un manque de securite, notamment 
5 pour les applications a risque telles que le paiement, la signature ou encore 
par exemple les applications DRM. 

Des exploits ont d'ailleurs montre qu'avec une erreur 
d'implementatlon, on pouvait passer outre ce systeme de permissions. 

Le deuxieme probleme du profil MIDP est pose par les specifications 
10 du profil MIDP lui-meme. II n'est pas adapte a la preuve formelle de 
programmes. Cela pose un probleme dans certains secteurs (notamment 
banquiers) ou une midlet ne peut etre modelisee par des methodes 
formelles, et done ne peut pas etre certifiee par ces methodes. 

En d'autres termes, il n'existe pas de technique permettant de 
15 prouver, par des methodes formelles, la validite par rapport a des 
specifications d'un programme programme dans ce profil. 

Un autre profil, le profil STIR, est lui plus specialement adapte pour 
donner acces a des APIs orientes quant a la securite, telles que Tacces a la 
SIM. 

20 Les machines virtuelles STIP (figure 3) permettent de faire 

fonctionner les programmes specialement ecrits pour le profil STIP. 

L'autre force de STIP est que son modele de programmation et ses 
APIs se pretent bien a I'analyse suivant les methodes formelles. Cela a 
permis d'ailleurs de rallier le milieu bancaire a son design, car la conformite 
25 du code aux specifications peut etre prouvee de maniere formelle, 

Aussi le profil STIP, utilise dans le milieu bancaire, est, par ses 
limitations, adapte a la preuve de programmes. 

Toutefois, le profil STIP a ete congu pour des systemes fermes (on 
nV telecharge pas impunement des applications dont on n'a pas 
30 confiance). 

Ainsi aucun modele de securite n*est mis en place (dans la version 
2.1.1. de la specification), et done toute application STIP (stiplet) peut 
acceder a n'importe quelle API de type STIP deja implementee. 
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Le profil STIP n'est done pas adapte pour la realisation de terminaux 
ou un utilisateur est susceptible de telecharger et mettre en oeuvre des 
applications courantes telles que jeux ou applications utilitaires divers. 

Uinvention se donne ici pour but de proposer une configuration 
5 permettant, dans un terminal de telecommunications, de mettre en oeuvre a 
la fois des applications d'utilisateur diverses, et a la fois des applications 
requerrant un haut niveau de securite. 

Uinvention vise en outre a facillter la programmation et la mise en 
oeuvre d'applications, notamment en facilitant la certification du bon 
10 fonctionnement des applications nouvellement programmees. 

On connaTt certes le principe des telepliones mobiles hebergeant 
deux machines virtuelles sous la forme physique de deux processeurs, I'un 
constitues par le terminal lui-meme et Tautre constitue par la carte SIM. 

La carte SIM verifie des exigences de securite elevees, tandis que le 
15 processeur du terminal lui-meme et son contenu sont, eux, accessibles par 
rutllisateur. 

Toutefois une telle implementation presente encore certains 
inconvenient majeurs. 

Ainsi un autre but de Tinvention est de proposer un dispositif, associe 

20 en reseau ou pas, dans lequel un espace securise et un espace non 
securise sont tous deux mis a profit, par exemple en permettant a I'espace 
securise d'acceder aux interfaces utilisateurs telles que clavier ou ecran a la 
place de i'espace non securise, et a contrario permettre par exemple a 
Tespace non securise d'acceder a une communication securisee avec un 

25 operateur connu pour garantir une telle securite. On citera notamment, en 
tant que tel operateur de securite, les operateurs de telephonie, notamment 
mobile, les banques, les fournisseurs d'objets multimedia a diffusion 
selective ou payante, les operateurs de fourniture de service centre 
signature electronique via ledit dispositif. 

30 Des fournisseurs d'objets multimedia a diffusion selective sont 

notamment les « DRM » ( Digital Rights Management, gestion des droits 
sous licence), serveurs qui delivrent un contenu typiquement musical,video 
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ou de jeu, sous licence, et sous la forme d'un fichier prevu pour etre lu sous 
diverses contraintes, par exemple un certain nombre de fois. 

Un but de invention est de proposer de teis moyens dans lesquels, 
en outre, on pulsse etre certain que les deux espaces d'executlon associes 
5 (run a securite plus elevee que Tautre) soient effectivement ceux qui etaient 
destines ou autorise a etre associes I'un a I'autre ab initio. 

Ces buts sont atteints selon {'invention grace a un dispositif 
informatique a interface utilisateur, comprenant des moyens de mise en 
oeuvre d'une serie d^applications, ces moyens incluant notamment un 

10 espace d'execution machine virtuelle/profil de fonctionnement, le dispositif 
comportant un s^cond espace d'execution machine virtuelle/profil de 
fonctionnement se distinguant du premier par au moins sa machine virtuelle 
ou son profil de fonctionnement, chaque espace d'execution hebergeant 
des applications, les applications du second espace d'execution etant des 

15 applications a degre de securite specifiquement plus eleve que celui des 
applications du premier espace d'execution du fait que les applications du 
premier espace d'execution sont des applications mises en places et 
activees par I'utilisateur du terminal tandis que les applications du second 
espace d'execution sont des applications non modifiables par I'utilisateur du 

20 terminal, caracterise en ce que les deux espaces d'execution sont heberges 
par un moyen physique de traitement qui est agence pour etre non 
scindable en deux parties sans destruction de ce moyen physique de 
traitement. 

On propose egalement selon I'invention un precede de mise en 
25 oeuvre d'applications au sein d'un dispositif informatique a interface 
utilisateur, le precede faisant appel a des moyens de mise en oeuvre d'une 
serie d'applications, ces moyens incluant notamment un espace d'execution 
machine virtuelle/profil de fonctionnement et un second espace d'execution 
machine virtuelle/profil de fonctionnement se distinguant du premier par au 
30 moins sa machine virtuelle ou son profil de fonctionnement, chaque espace 
d'execution hebergeant des applications, les applications du second espace 
d'execution etant des applications a degre de securite specifiquement plus 
eleve que celui des applications du premier espace d'execution du fait que 
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les applications du premier espace d'execution sont des applications mises 
en place et activees par I'utilisateur du terminal tandis que les applications 
du second espace d'execution sont des applications non modifiables par 
I'utilisateur du terminal, caracterise en ce que les deux espaces d'execution 
5 sont heberges par un moyen physique de traitement qui est agence pour 
etre non scindable en deux parties sans destruction de ce moyen physique 
de traitement. 

D'autres caracteristiques, buts et avantages de invention 
apparaTtront a la lecture de la description detaillee qui va suivre, faite en 
10 reference aux figures annexees sur lesquelles : 

- la figure 1 est un schema illustrant une implementation MIDP selon 
I'art anterieur ; 

- la figure 2 est un schema illustrant la mise en oeuvre de moyens de 
protection dans une telle implementation MIDP ; 

15 - la figure 3 est un schema illustrant une implementation STIR, 

conforme a Tart anterieur ; 

- la figure 4 illustre une configuration fonctionnelle d'un terminal 
conforme a Tinvention, selon une variante preferentielle. 

Le mode particulier de realisation que Ton decrira maintenant permet 
20 de beneficier du meilleur des deux techniques MIDP et STIP, donnees a 
titre d'exemple, au sein d'un environnement d'execution coherent. 

On y constitue le profil « utilisateur », le profil MIDP. Ce profil est tres 
populaire dans le monde mobile pour la creation de jeux et d'applications 
utilitaires diverses. L'utilisateur peut ainsi telecharger et executer des 
25 applications qu'il trouve sur le reseau, comme il le ferait avec un telephone 
MIDP courant. Le profil MIDP inclut done ici des applications mises en 
place et activees par I'utilisateur lui-meme. 

Le profil STIP constitue ici un profil additionnel, et plus 
specifiquement un profil « operateur ». Le profil STIP est tres adapts aux 
30 applications qui demandent un haut niveau de securite, telles que les 
applications bancaires. Ainsi, les consortiums bancaires ont deja fait 
confiance en la possibilite de certifier des applications STIP par des 
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methodes formelles pour les implementer dans des terminaux de paiement 
electronique (TPE). 

La presente invention permet done de fournir aux developpeurs un 
ensemble d'API operateur dont {'execution est assuree dans un espace 
5 d'execution approprie a la programmation aisee par ces developpeurs, 
espace de meme profil ou non, totalement distinct. 

Ce mode de realisation permet done a I'operateur de fournir un lot 
d'applications securisees, telles que paiement, de signature ou encore de 
DRM, totalement independant du profil d'execution des applications 
10 « courantes ». 

Le terminal represents en figure 4 inclut et fait fonctionner en 
harmonie deux machines virtuelles 100 et 200 de profil distincts P1 et P2 
(ou non). L'une 100 des deux machines est dediee aux applications 
utilisateurs, Tautre 200 aux applications de I'operateur. 
15 Les profils correspondants PI et P2, ici respectivement le profil 

MIDP et le profil STIP, sont ici eux-memes dedies respectivement aux 
applications utilisateur et aux applications operateur. 

A la figure 4, on a represents ainsi deux machines virtuelles 1 00 et 

200. 

20 La machine virtuelle « utilisateur » 1 00 est mise a disposition de 

I'utilisateur pour telecharger, installer, desinstaller, executer, stopper, 
comme bon lui semble des applications dans le profil MIDP. Les 
applications 110 qui y tournent utilisent I'API 120 de ce profil, ainsi qu'une 
API « stub » au meme profil que celui de la machine 100, cette API stub 

25 etant referencee 130 sur la figure 4. 

La deuxieme machine, referencee 200, est la machine virtuelle 
« operateur » : seul I'operateur, par exemple Toperateur de telephonie 
mobile ou encore Toperateur internet (fournisseur d'acces), par un 
mecanisme OTA (Over The Air), peut administrer cet espace d'execution. 

30 II peut y installer, desinstaller, activer, desactiver comme bon lui 

semble des applications 210 ecrites suivant le formalisme du profil 100. Ces 
applications 210 ont acces aux APIs 220 du profil P2 et a une ou plusieurs 
API de haut niveau illustrees sous la reference 230 sur la figure 4. 
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Ces API de haut niveau 230 permettent d'acceder a des services 
offerts par le profil de la machine 100. L'acces aux APIs, que ce soit du 
profil de la machine 200 ou du stub 230 au profil de la machine 100, se fait 
suivant le modele de securite inherent au profil de la machine 200. 
5 L'API « stub » 130 est une API de haut niveau, exprimee suivant le 

modele de programmation du profil 100, permettant d'acceder a des 
services offerts par le profil P2. L'acces aux APIs, que ce soit au profil de la 
machine 100 ou d'un stub 130 se fait suivant le modele de securite inherent 
au profil PI de la machine 100. 
10 Le fonctionnement des stubs 1 30 et 230 est le suivant : 

L'appel a une API du stub 130, 230 est transforme en flux d'octets 
(processus de serialisation, ou marshalling/unmarshalling suivant les 
appellations). 

Ce flux est regu par un manager 140, 240 du profil oppose via un 
15 canal de communication 300, deserialise et converti en Texecution d'une 
procedure dans le profil distant. Le retour d'execution de cette procedure 
est de nouveau serialise dans le profil distant, et repasse dans le canal de 
communication 300 entre les deux profils PI et P2 des machines 100 et 
200, la reponse est deserialisee dans le profil originel et transformee en 
20 retour d'appel de I'API « stub ». 

Ainsi, on dispose de deux espaces d'execution independants 
consistant ici chacun en une machine differente et un profil different, et en 
relation tres etroite par I'intermediaire d'API stub 130 et 230. 

En variante, les deux profils PI et P2 peuvent etre du meme type, 
25 par exemple deux profils MIDP ou deux profils STIP pour deux machines 
differentes. 

On notera egalement que Ton peut adopter deux profils PI et p2 
differents au sein d'une meme machine virtuelle. 

Ce mode de realisation permet done d'offrir une API de paiement 
30 aux developpeurs d'applicatio.ns MIDP, ou le paiement lui-meme 
s'effectuera dans le cadre de Texecution d*une machine virtuelle STIP 
controlee par Toperateur. 
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En d'autres termes, une application Ml DP, developpe aisement, 
pourra offrir un moyen de paiement a I'utilisateur en faisant fonctionner une 
application de paiement de la machine 200 via le lien de communication 
300. Une application MIDP est done, grace a Tinvention, capable d'offrir une 
5 fonctionnalite de paiement de grande fiabilite. 

Les deux espaces d'execution, 100 et 200, chacun constitue par un 

* 

couple machine virtuelle/profil d'execution, differents Tun de Tautre par le 
profil ou par la machine virtuelle, sent toutefois tous deux implementes par 
une meme dispositif physique de traitement 400 (meme entite hardware 
10 400). 

Ce dispositif de traitement hebergeant les deux espaces d'execution 
est unique en ce sens qu1l ne peut etre scinde sans destruction de son 
fonctionnement. 

Ainsi il est impossible de separer physiquement les deux espaces 
15 d'execution, et done egalement impossible d'associer un espace ainsi 
separe avec un autre espace, lui non autorise. 

Un telle realisation sur moyen unique est obtenue par exemple en 
implementant les deux espaces d'execution sur un meme circuit integre 
formant un unique processeur. 
20 On assure ainsi que deux environnements. Tun securise et Tautre 

non securise, sont indissociables. 

La securite proposee par un operateur (telephonie, banque, 
administration a signature, diffuseur multimedia) s'en trouve amelioree, qu1l 
s'agisse d'empecher des detournements de fonctions de paiement, 
25 d'assurer la confidentialite ou la non falsification de codes secrets, de 
fiabiliser I'usage d'une signature electronique, ou encore de veiller a 
empecher de depasser des droits d'utilisation limites d'oeuvres payantes. 

Avantageusement, les profils P1 , P2 de chacun des deux espaces 
d'execution 100, PI, 200, P2 sont respectivement un profil STIP et un profil 
30 faisant partie du groupe constitue des profils STIP, MIDP, OSGl, et « .net ». 



wo 2005/071925 



9 



PCT/FR2004/003284 



REVENDICATIONS 

5 

1. Dispositif informatique a interface utilisateur, comprenant des 
moyens de mise en oeuvre d'une serie d'applications, ces moyens incluant 
notamment un espace d'execution machine virtuelle/profil de 
fonctionnennent (100, P1, 200, P2), le dispositif comportant un second 

10 espace d'execution machine virtuelle/profil de fonctionnement (100, PI, 
200, P2) se distinguant du premier par au moins sa machine virtuelle (100, 
200) ou son profil de fonctionnement (P1, P2), chaque espace d'execution 
hebergeant des applications (110, 120, 130, 140, 220, 230), les 
applications du second espace d'execution (100, P1, 200, P2) etant des 

15 applications a degre de securite specifiquement plus eleve que celui des 
applications du premier espace d'execution (100, PI, 200, P2) du fait que 
les applications (110, 120, 130, 210, 220, 230) du premier espace 
d'execution (100, PI, 200, P2) sont des applications modifiables par 
I'utilisateur tandis que les applications (110, 120, 130, 210, 220, 230) du 

20 second espace d'execution (100, PI, 200, P2) sont des applications non 
modifiables par Tutilisateur, caracterise en ce que les deux espaces 
d'execution sont heberges par un meme moyen physique de traitement 
(400) qui est agence pour etre non scindable en deux parties sans 
destruction de ce moyen physique de traitement (400). 

25 2. Dispositif selon la revendication 1, caracterise en ce que les 

applications (110, 120, 130, 210, 220, 230) du second espace d'execution 
(100, PI, 200, P2) sont des applications modifiables par un operateur de 
securite appartenant au groupe constitue des operateurs de telephonie, 
banques, fournisseurs d'objets multimedia a diffusion selective ou payante, 

30 operateurs de fourniture de services centre signature electronique via ledit 
dispositif. 

3. Dispositif selon la revendication 1 ou la revendication 2, 
caracterise en ce qu'il constitue un terminal telephonique. 
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4. Dispositif selon la revendication 3, caracterise en ce qu1l constitue 
un terminal de telephonie mobile. 

5. Dispositif selon Tune quelconque des revendications precedentes, 
caracterise en ce qu'il comporte des moyens de communication (130, 230, 

5 300) entre les deux espaces d'execution (100, P1 , 200, P2). 

6. Dispositif selon la revendication 5, caracterise en ce que les 
moyens de communication (130, 230, 300) entre les deux espaces 
d'execution sont prevus pour autoriser une application (130, 230) d'un des 
deux espaces d'execution a faire appel a des moyens de traitement du 

10 second espace d'execution (100, P1, 200, P2). 

7. Dispositif selon Tune quelconque des revendications precedentes, 
caracterise en ce que chacun des deux espaces d'execution inclut au 
moins une API distincte (120, 130, 220, 230). 

8. Dispositif selon Tune quelconque des revendications precedentes, 
15 caracterise en ce que les moyens de communication incluent une API 

« stub » (130, 230) ayant pour role de faire appel a des ressources de 
Tespace d'execution oppose (100, PI, 200, P2), ces ressources mettant en 
oeuvre une selection quant a I'acces a elles-memes en fonction de 
I'application (110, 210) les appelant. 
20 9. Dispositif selon Tune quelconque des revendications precedentes, 

caracterise en ce que les moyens de communication entre les deux 
espaces d'execution (100, P1, 200, P2) incluent des moyens mettant en 
oeuvre une serialisation/deserialisation ou un marshalling/unmarshalling. 

10. Dispositif selon Tune quelconque des revendications 
25 precedentes, caracterise en ce que I'un des deux espaces d'execution 

(100, PI, 200, P2) inclut un profit de type STIP. 

11. Dispositif selon Tune quelconque des revendications 
precedentes, caracterise en ce que I'un des deux espaces d'execution 
(100, PI, 200, P2) inclut un profil MIDP. 

30 12. Dispositif selon Tune quelconque des revendications 

precedentes, caracterise en ce que les profils (PI , P2) de chacun des deux 
espaces d'execution (100, P1, 200, P2) sont respectivement un profil STIP 



wo 2005/071925 



11 



PCT/FR2004/003284 



et un profil faisant partie du groupe constitue des profils STIP, MIDP, OSGI, 
et « .net ». 

13. Procede de mise en cBuvre d'applications au sein d'un dispositif 
informatique a interface utilisateur, le procede faisant appel a des moyens 
5 de nnise en oeuvre d'une serie d'appiications, ces moyens incluant 
notamment un espace d'execution maciiine virtuelle/profil de 
fonctionnement (100, PI, 200, P2) et un second espace d'execution 
machine virtuelle/profil de fonctionnement (100, P1, 200, P2) se distinguant 
du premier par au moins sa machine virtuelle (100, 200) ou son profil de 

10 fonctionnement (PI, P2), chaque espace d'execution (100, PI, 200, P2) 
hebergeant des applications, les applications du second espace d'execution 
(100, PI, 200, P2) etant des applications a degre de securite 
specifiquement plus eleve que celui des applications du premier espace 
d'execution (100, PI, 200, P2) du fait que les applications (110, 120, 130, 

15 210, 220, 230) du premier espace d'execution (100, PI, 200, P2) sont des 
applications modifiables par I'utilisateur tandis que les applications (110, 
120, 130, 210, 220, 230) du second espace d'execution (100, P1, 200, P2) 
sont des applications non modifiables par I'utilisateur, caracterise en ce que 
les deux espaces d'execution sont heberges par un meme moyen physique 

20 de traitement (400) qui est agence pour etre non scindable en deux parties 
sans destruction de ce moyen physique de traitement (400). 
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